Service Based Local Policy
IMS, (IP Multimedia Subsystem), is a 3G subsystem specification that enables enriched Internet Protocol based services over access technologies such as, WCDMA, CDMA2000 and GERAN. Exemplary IMS services are: Voice over IP telephony, multi-party conference calls, also denoted push-to-talk, video conferencing, file downloading, music on demand etc. Numerous other services are foreseen to be enabled by the IMS. The IMS is specified in 3GPP standards, e.g. in 3GPP TS 23.228 (IMS), TS 23.002 (Network architecture) and TS 23.207 (end-to-end QoS). These services are believed to offer enhanced value to users and consequently offer operators the possibility of in-creased revenues.
The above services would be associated with various quality of service (QoS) classes.
In order to ensure that services can be offered to users and to apply a policy such that users “get what they have paid for”, but not more than that, QoS management functions are set out in the IMS system. The Policy Decision Function (PDF) and Application Function (AF) defined in TS 23.207 are IMS network elements, which secures these functions.
The PDF functions as a Policy Decision Point for the Service Base Local Policy (SBLP) and makes policy decisions based on policy set up information received from the AF and provides final policy decisions controlling the allocated QoS resources for the authorised media streams by transferring the decision to the GGSN.
The application function (AF) secures that suitable IP bearer resources can be assigned to the user equipment (UE) corresponding to the given communication (application type) the user attempts to establish (TS 23.207, c.f. section 5.2.4). The AF indicates to the PDF whether or not the PDF should contact the AF at UE resource reservation and indicates to the PDF whether media should be enabled or disabled.
The signaling procedure for SBLP involved in the authorization method according to 3GPP has been shown in FIG. 2 (corresponds to TS 23.228(IMS) and TS 29.208(SBLP)):    1) For a mobile originated (MO) call, the UE sends a SIP Initialisation message to the AF (P-CSCF) indicating a session. For a mobile terminated (MT) call, the AF (P-SCCF) receives a SIP message from another mobile or fixed terminal.    2) The AF requests the PDF for a token associated with this session request (SIP initialisation message) and makes an indication for a corresponding QoS.    3) The PDF examines the request and if it can be accepted assigns a suitable QoS, which may normally not deviate from the QoS indicated in step 2) and generates a token (containing a PDF identifier (note: the network may include multiple PDF's); a session identifier and the assigned QoS for the session) and sends it to the AF over the Gq interface. The token and associated assigned QoS is stored in the PDF to be used in step 6).    4) The AF sends the token to the UE, using SIP signaling. The signaling includes the assigned QoS to be used for the session.    5) The UE performs a PDP context Activation Request/(Token) involving activating a secondary PDP Context for this new service according to a requested QoS and sends the token, previously received, as part of the Activation request (PS: the token including the “required” QoS may potentially be hampered by a rogue UE, indicating a higher required QoS than assigned).    6) The GGSN sends an Authorise (Request) message including the token received in the secondary PDP context Activation to the PDF, indicated by the token, on the Go interface.    7) The PDF evaluates that the token received from the UE corresponds to the token the AF previously issued, i.e. that the requested QoS does not exceed the assigned QoS for the service. The PDF sends a grant (Acknowledge including a negotiated QoS) (or deny) back to the GGSN and includes the filters to apply to the PDP Context in order for GGSN to do policing. If the requested QoS is higher than the assigned QoS, the PDF may downgrade the QoS to a “negotiated” lower QoS.    8) Set-up is carried out in the GGSN such that only packets belonging to the correct session are passed through the PDP Context. Other packets are stopped, dropped or handled in some other way, but not delivered to the destination. (Thereby, the User Equipment will not be served with a higher service class than paid for).    9) The GGSN sends back the PDP Context Activation Accept to the UE and the UE can start sending data in (the tunnel established according to) the new secondary PDP Context.Alternative Known Architecture
In FIG. 1b, an alternative known architecture has been shown relating TS23.254-6 Annex F.
According to FIG. 1b, an interface Gn′ is provided between the packet data gateway and the GGSN such that the packet data gateway can access the Internet through a GGSN. No Wi interface is provided between the PDG and the Internet. A component denoted Tunnel Termination Gateway (TTG) residing in the PDG achieves connectivity with the GGSN, where the GGSN can take over some of the PDG functions e.g. charging functions. Hence, the known PDG functionality is performed by the PDG and the GGSN in common.
It should be noted that, the PDG of FIG. 1b is not capable of controlling QoS towards the 3G core-network for a WLAN user equipment.
WLAN/3G Integration
There is standardization work ongoing to integrate WLAN access, (Wireless-Local Access Network), such as specified according to the IEEE 802.11 series of protocols with the core network of GSM/GERAN/3G (Groupe Speciale Mobile/EDGE/3rd generation mobile telephony-UMTS). The work is ongoing in 3GPP (3rd Generation Partnership Project), 3GPP2 and IEEE. Six scenarios for various degree of integration have been defined in 3GPP. Scenarios 1, 2 and 3 have been discussed so far as indicated in TS 23.234.
The work for scenario 3, i.e. WLAN GSM/3G integration of data services is specified in stage 2 in TS 23.234 supporting data services (IMS, MMS, SMS) to operators mobile home network. In the TS 22.234 it is specified that IMS should be possible to provide over WLAN.
Most WLAN's deployed today are 802.11b systems. These systems do not have QoS support and therefore are not subject to the SBLP (Service Based Local Policy) explained above. However, in IEEE there is a standardization effort going on in 802.11e topic group to specify QoS support for 802.11 systems.
The WLAN/3GPP architecture specified in TS 23.234 is shown in FIG. 1. The WLAN UE can access WLAN Access Network and do security procedures towards the 3G Home Network using the Wa interface via the 3GPP AAA Server. This is the scenario 2 according to the 3GPP scope.
For scenario 3, i.e. WLAN GSM/3G integration of data services, the WLAN UE sets up a tunnel on the Wu interface to a PDG (Packet Data Gateway), in order to access 3G data services and other data services via the Wi interface. This tunnel is assumed to be an IP Sec tunnel, end-to-end between the UE and the PDG, and will be used for multiplexing all data traffic services.
The problem with the existing WLAN solution is that there is no mechanism for controlling QoS towards the 3G-core network.